昨天向大家介紹了 EFK 架構與合作關係以及 EFK 架構圖，在今天的分享中我會將 EFK Log 資訊收集系統中一個一個的元件部署到Kubernetes上

EFK－Elasticsearch

Elasticsearch是一套分散式的 Log 訊息搜尋引擎。基於 Apache Lucene(TM) 所開發的搜尋引擎，可以透過全文搜尋、結構化搜尋和分析這三種功能組合再一起搜尋 Log 訊息，此外 Elasticsearch 具有高擴展性、高可用性、易管理等特點。

部署到Kubernetes上

首先我們要先確認 EFK Log 資訊收集系統 其中的 Elasticsearch 要使用哪一個版本，這邊我使用的版本是 6.4.3 版。

issue01－Production mode問題

按照Elasticsearch Production mode的建議說明指出若是要將此環境設計為 Production mode 需要調整Linux Kernel 中的 max_map_count 參數。

在裸機(bare metal)或是Container環境，我們經常會在啟動腳本裡面透過 sysctl 這個指令修改 Linux Kernel 中的 max_map_count 大小。

sysctl -w vm.max_map_count=262144

但是在 Kubernetes 中並不支援這種行為，Kubernets 的issue 列表中也有許多討論配置 max_map_count 的相關問題，例如3595 issue。

目前看到大多數解決此問題的方式是透過 sidecar 的方式進行處理。

issue02－角色問題

由於 Elasticsearch 系統可以以多節點叢集的方式進行部署與建置，節點大致上可以分為兩個角色分別是 Master Node 以及 Data Node，其他還有如 Ingest Node 等等為了保持簡單能夠讓讀者理解 Elasticsearch ，其他的角色本文將不進行探討。

• Data 角色
  節點若是擔任該角色的話，表示此節點主要是用於儲存資料，對資料進行 Search 、 Aggregations 與 CRUD 等操作。

• Master Eligible 角色
  負責與其他同為 Master Eligible 角色的節點進行投票選出操作 Elasticsearch 叢集的 Master 節點，並且當聯繫不上 Master 節點的話，所有身為 Master Eligible 角色的節點會再重新同票選出新的 Master 節點。

• Master 角色
  由Master Eligible 角色選舉出來的，負責管理 Elasticsearch 叢集，通過廣播機制與叢集中其他節點維持關係，此為還需要處理叢集中的新增與刪除索引等操作。

issue03－永久性儲存問題

我們需要一個擁有性儲存的空間儲放 Log 資訊，避免 Elasticsearch 節點故障導致資料遺失。

今天提到了三個在部署叢集式的 Elasticsearch 將會遇到的問題，這邊先記住有這幾個這個需要特別注意的，明天將會示範如何在 Kubernetes 上部署叢集式的 Elasticsearch 到時候會一一介紹這些問題如何解決。